@Mugen87 Can you comment on the advisability of this?

(I added a milestone so this does not get lost again.)

I don't think we should expose the render target creation. I suggest to provide a solution in the engine that should satisfy most use cases:

• Set the size of the transmission render target to half of the drawing buffer's size. That should be a good approximation and solve the aspect ratio issue. Adding something like below in renderTransmissionPass() should also handle resize scenarios:

_this.getDrawingBufferSize( _vector2 ).multiplyScalar( 0.5 ).floor();
_transmissionRenderTarget.setSize( _vector2.x, _vector2.y );

• Stop WebGL 1 support for MeshPhysicalMaterial.transmission to easier implement the above solution.
• Using LinearFilter for magFilter should be safe, too.

@Mugen87 Your suggestion sounds good to me! 👍

Closing in favor of #23450.

Going against the grain here, but that'd be a step backward from my pov – WebGL1 is the primary target we work with so it'd be a shame to lose transmission there. Getting the aspect ratio to match the drawing buffer helps quality in the simple case but we're often making multiple passes of a scene at different resolutions

I'd rather have a 1024 x 1024 buffer that worked everywhere than something canvas size bound and limited to WebGL2

But better still would be some way to access the transmission buffer, doesn't need to be documented or explicitly public however

WebGL1 is the primary target we work with so it'd be a shame to lose transmission there

Do you mind sharing some details of why is WebGL1 your primary target?

And what's your approach for getting good results with WebGL1? Maybe that's something we can add in the renderer instead.

But better still would be some way to access the transmission buffer, doesn't need to be documented or explicitly public however

We prefer to not add new methods whenever we can to avoid more maintenance work.

Do you mind sharing some details of why is WebGL1 your primary target?

Projects are usually mobile-first and often clients focus on iOS for minimum spec requirements where WebGL2 support is still lagging sadly

And what's your approach for getting good results with WebGL1? Maybe that's something we can add in the renderer instead.

Locally I've used

var transmissionSize = renderer.capabilities.isWebGL2 ? targetSize : floorPOT(targetSize);

The problem with separate camera passes requiring separate transmission sizes is what motivates exposing this so the user can fix problems but I totally get what you're saying about reducing maintenance surface

The perfect solution would be three.js would allocate transmission buffers as needed with dimensions corresponding to the render targets dimensions (and clearing them if not used in the next frame for example), I use a renderTargetStore approach to manage this